Increasingly, copyrightable content is being distributed in digital form on various physical media types, including Digital Versatile Disk (DVD). While digital content, such as video and music, has provided greater fidelity to the consumer, it has the significant drawback of being relatively easy to reproduce perfect copies of the content without the authorization of the copyright owner. Because digital content may be copied at any point along the path through which it is transmitted, a number of security measures are usually utilized in combination.
One such security measure revolves around the use of data or content encryption. Generally, digital content is encrypted and then recorded onto a chosen media. A pre-selected key(s) is then employed by playback devices to decrypt the digital content in order to play it. One drawback with this technology is that once the key(s) has been compromised, unauthorized parties may build devices to copy the decrypted digital content. Said compromised key(s) cannot be revoked without unduly burdening consumers and/or authorized electronic device manufacturers.
An alternative method of digital content protection has been proposed and implemented by an industry organization named the 4C Entity, LLC, which is comprised of International Business Machines Corp., Intel Corp., Matsushita Electric Industries Corp., and Toshiba Corp. The 4C Entity describes their method of content protection in a publication entitled “Content Protection For Recordable Media Specifications” (CPRM), Rev. 0.94, Oct. 18, 2000. CPRM, and its equivalent for pre-recorded media, Content Protection For Pre-Recorded Media (CPPM), define a renewable method for protecting content recorded on a number of physical media types which allows for the revocation or invalidation of any key(s) which may have been compromised. For purposes of this document, all disclosures with respect to CPRM are also understood to apply to CPPM.
Digital content protection under CPRM generally works as follows, although the details may vary among different implementations. The 4C Entity provides one or more secret Device Key(s) to each device manufacturer for inclusion into each CPRM-compliant device produced.
As illustrated in FIG. 1, manufacturers of physical media for digital content place a Media Identifier (MID) 102 and the Media Key Block (MKB) 104, generated by the 4C Entity, on each piece of compliant media 100. In one implementation, the physical media 100 may be a rotational disk, such as a DVD. When compliant media 100 is placed within a compliant drive or player/recorder, a secret Media Key is generated by the device using its Device Key(s) and the MKB 104 stored on the media itself. The same secret Media Key is generated regardless of which compliant device is used to access the media. Content 106 stored on the media 100 is encrypted/decrypted by a Content Key from a one-way function of a secret Title Key and the copy control information (CCI) associated with the content. The Title Key is encrypted and stored on the media using a key derived from a one-way function of the Media Key and MID.
In one implementation, each Device Key has an associated column and row value which relate to the columns and rows of the MKB. For example a Device Key X may be associated with column 4, row 7. For a given device, no two Device Keys have the same associated column value. The number of Device Keys given to each device varies depending on the implementation.
As illustrated in FIG. 2A, the MKB 200 may be formatted as a sequence of contiguous records 204, hereinafter referred to as Media Key Record(s) (MKR). In order to decrypt the digital content, a compliant device uses its Device Key(s) to calculate a Media Key by processing records of the MKB 200 one-by-one, from first to last.
Thus, if a particular Device Key becomes compromised in a way that threatens the integrity of the system, the 4C Entity may “revoke” that Device Key by providing media manufacturers with a new MKB to be stored on new media. The new MKB causes devices with the compromised Device Key to calculate a Media Key which is different than that which is computed by compliant devices, thereby preventing the decryption of the digital content stored on that media. The device may still utilize one of its other Device Keys, if available, to calculate the Media Key that decrypts the digital content.
However, one disadvantage of this security method is the latency caused by reading of the MKB 200. Before playing or accessing the digital content, each compliant device must read the MKB 200 to decrypt the digital content. A MKB 200 can be quite large, typically 3 megabytes (Mbytes) or larger. However, there is no size limit for a MKB per se; the size being merely dictated by the number of Device Keys which have been revoked. In time, the size of a MKB may increase as a result of such revocations. Consequently, the time to process a large MKB 200 can be significant, causing a perceptible nuisance to the user trying to enjoy the content.
In order to appreciate this problem, some additional background information on the MKB 200 is necessary. As illustrated in FIG. 2A, a MKB 200 is comprised of a contiguous sequence of Media Key Records (MKR) 204.
The first record, or MKR, in a MKB 200 is called the Verify Media Key Record 202 and is illustrated in FIG. 2B. This record serves an optimizing function, allowing a device to more quickly terminate the decryption process if the correct Media Key has been calculated. That is, if a particular Device Key and MKR yields a Media Key which satisfies the verifying algorithm, found within the Verification Data field 214, then processing of the MKB 200 may stop and the encrypted data may be decrypted.
Every MKB 200 also has one Calculate Media Key Record (CMKR) 230, illustrated in FIG. 2C. The CMKR 230 is used by the device to calculate a Media Key. The device uses the column and row numbers associated with a particular Device Key to match to the Column field 234 and index to the corresponding Encrypted Key Data field 236, 238, 240, 242, or 244 associated with the row. The Encrypted Key Data field 236, 238, 240, 242, or 244 is employed by the device, in conjunction with its Device Key(s) to calculate a Media Key.
Additionally, the MKB 200 may contain one or more Conditionally Calculate Media Key Records (CCMKR) 250, which is another type of MKR. As illustrated in FIG. 2D, each CCMKR 250 may have a header comprising encrypted information 270, which must be decrypted before processing, and a plurality of doubly Encrypted Key Data fields 272. Like with CMKRs, the device uses an Encrypted Key Data field 260, 262, 264, 266, or 268 in conjunction with Device Key(s) to calculate and update the Media Key.
FIG. 3A illustrates the protocol for accessing a conventional Media Key Record 300. For each MKR 300, a device must first seek and transfer a block containing the record header 302. If the Column field 234 (in FIG. 2C) or 274 (FIG. 2D) of the MKR 300 matches the column value associated with Device Key, then the device must index into the Encrypted Key Data field 304 corresponding to the row associated with the Device Key. Obtaining the Encrypted Key Data 304 may require at least one additional seek and read operation. Thus for each record, at least two read and two seek operations may be required; the first seek and read operations for accessing the MKR header 302 and the second seek and read operations for accessing the Encrypted Key Data 304.
Note that the number of read operations will vary depending on the block size. That is, physical media types may be formatted into different block sizes; the block size being the transfer unit or number of bytes that may be transferred in a single read operation. For DVD-compliant media, the transfer unit is know as known as the Error Control Code (ECC) block; each ECC block comprising 32,768 bytes.
FIG. 3B illustrates another scenario when accessing a Media Key Record 350. In this example, the Encrypted Key Data field 354 spans two blocks 362 and 364. Hence, an additional read operation is required under this circumstance.
Accordingly, there is a need for a system to optimize the processing and/or formatting of a Media Key Block so as to minimize user-perceptible delays.